Introducing profiles

After a lot of discussion in the dev channels, I've added a new concept in Wolf: profiles. This will be particularly useful for wolf-ui which will be the new entrypoint when starting a Moonlight streaming session and will allow to:

• easily pick up a profile and start an app (this will allow you to carry over savegames and state between different Moonlight clients)
• easily join another streaming session for co-op playing.

The format in config.toml is the following

[[profiles]]
id = 'moonlight-profile-id'

    [[profiles.apps]]
    title = 'Wolf UI'

        [profiles.apps.runner]
        run_cmd = '/home/ale/repos/wolf-ui/src/wolf-ui'
        type = 'process'

    [[profiles.apps]]
    start_audio_server = false
    start_virtual_compositor = false
    title = 'Test ball'

        [profiles.apps.audio]
        source = 'audiotestsrc wave=ticks is-live=true'

        [profiles.apps.runner]
        run_cmd = "sh -c \"while :; do echo 'running...'; sleep 10; done\""
        type = 'process'

        [profiles.apps.video]
        source = '''videotestsrc pattern=ball flip=true is-live=true !
                           video/x-raw, framerate={fps}/1''' 

[[profiles]]
id = 'user'
name = 'User'
apps = []

We'll automatically migrate from the current config.toml by:

• Adding the hardcoded moonlight-profile-id which will represent the apps that are going to be shown in the Moonlight UI
• Adding a default user profile and copying over all the previously defined apps in here.

APIs

The currently available /api/v1/apps will now control the apps that will be shown in the Moonlight UI. There are 3 new endpoints to control profiles:

• GET /api/v1/profiles returns a list of all defined profiles (most notably it wouldn't return the special "moonlight" profile, you'll have to use /api/v1/apps to interact with that one)
• POST /api/v1/profiles/add takes a full profile object
• POST /api/v1/profiles/remove takes just an id: the ID of the profile to be deleted

Hitting any of the apps or profiles endpoints will also automatically save the changes into the config.toml (if any).

I've yet to define how to associate streaming sessions with profiles and how that will play with CO-OP sessions, I'll start working on that now.

@Skerga, @salty2011 please let me know what you guys think and what else you would like to see added!

Introducing Lobbies

On top of profiles we are also introducing Lobbies, here are the highlights:

Key Features

• Easy Co-op Session Joining:

  • Users can now seamlessly join cooperative game sessions from different Moonlight clients

• Session Continuity Across Devices:

  • Start a gaming session on one device and continue it on another one without losing progress.

• Watch Parties:

  • This will also make possible "watch parties" where users can observe game sessions without interacting. This is perfect for spectators who want to follow along without affecting the gameplay.

Here is my list of things that would still be required for me to deem this branch beta test ready.

• A rebase of the branch.
• Entry in the config defining how an Apps save folder should be named. Possibly something like directory_name that
  can be optional and would default to either the title or the runner.name.
  this includes maybe defining how wolf-ui should structure profile data. the currently implemented way is:
  (/etc/wolf/)profile-data/{profile_id}/{app.runner.name}
• The same as above but for co-op lobbies, in case a user would like to keep a separate install for co-op play,
  would default to the one above if not used.

Optional stuff that would be nice to have but can wait if necessary:

• A Keybind that would allow to return back to Wolf-Ui without directly stopping the Lobby the app is running in,
  including leaving the lobby. (Wolf-UI has logic that allows a user to rejoin a lobby, so switching devices would be
  easier.)
• Setting a Pin for a Profile. currently all profiles are open by default.
• Accessing Images defined in icon_png_path via the wolf api if its a local png. this way i could drop access to the folder
  containing the images from wolf-ui's requirements. wolf-ui is capable of using urls by itself and does already access
  the icons on github if icon_png_path is not defined.
• API call to pull and update docker images, with some form of progress feedback. This would allow me to keep the
  current update function without the need to access the docker socket and allow wolf-ui to be run less privileged.
• an API endpoint to check if an Apps Docker Image exists on Disk, see reason above.

Current status

Everything is pretty much wired together and working, see the short video below (youtube link):

There are two main issues remaining:

• On AMD: (I suppose Mesa in general) leaving a session on one resolution and joining from a device that asks for a bigger resolution causes a kernel panic. Not sure if this is specific to my dev machine, kernel version, etc. should be fixed now
• On Nvidia: when any user stops a stream (either by leaving a lobby or by force closing from Moonlight) every other Wayland session running will crash.
  • This is tied to the fact that the zero copy video encoding pipeline needs to use some OpenGL elements (glupload and glcolorconvert to pass the DMA buffer into nv*enc) and when they get destroyed they'll trash some global context (I guess) that will mess up with our custom compositor (which uses OpenGL to render) causing it to crash.
  • this issue is also present on :stable
  • not sure how to get around this, I'll try to share the OpenGL context from gst-wayland-comp to the downstream gl elements, but I'm afraid it's fairly complicated